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Abstract 


This document specifies a TLS 1.3 extension that allows a server to authenticate with a 
combination of a certificate and an external pre-shared key (PSK). 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for examination, 
experimental implementation, and evaluation. 


This document defines an Experimental Protocol for the Internet community. This document is a 
product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for publication by the Internet 
Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for 
any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8773. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


The TLS 1.3 [RFC8446] handshake protocol provides two mutually exclusive forms of server 
authentication. First, the server can be authenticated by providing a signature certificate and 
creating a valid digital signature to demonstrate that it possesses the corresponding private key. 
Second, the server can be authenticated by demonstrating that it possesses a pre-shared key 
(PSK) that was established by a previous handshake. A PSK that is established in this fashion is 
called a resumption PSK. A PSK that is established by any other means is called an external PSK. 
This document specifies a TLS 1.3 extension permitting certificate-based server authentication to 
be combined with an external PSK as an input to the TLS 1.3 key schedule. 
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Several implementors wanted to gain more experience with this specification before producing a 
Standards Track RFC. As a result, this specification is being published as an Experimental RFC to 
enable interoperable implementations and gain deployment and operational experience. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. Motivation and Design Rationale 


The development of a large-scale quantum computer would pose a serious challenge for the 
cryptographic algorithms that are widely deployed today, including the digital signature 
algorithms that are used to authenticate the server in the TLS 1.3 handshake protocol. It is an 
open question whether or not it is feasible to build a large-scale quantum computer, and if so, 
when that might happen. However, if such a quantum computer is invented, many of the 
cryptographic algorithms and the security protocols that use them would become vulnerable. 


The TLS 1.3 handshake protocol employs key agreement algorithms and digital signature 
algorithms that could be broken by the development of a large-scale quantum computer 
[TRANSITION]. The key agreement algorithms include Diffie-Hellman (DH) [DH1976] and Elliptic 
Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital signature algorithms include RSA [RFC8017] 
and the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary 
that stores a TLS 1.3 handshake protocol exchange today could decrypt the associated encrypted 
communications in the future when a large-scale quantum computer becomes available. 


In the near term, this document describes a TLS 1.3 extension to protect today's communications 
from the future invention of a large-scale quantum computer by providing a strong external PSK 
as an input to the TLS 1.3 key schedule while preserving the authentication provided by the 
existing certificate and digital signature mechanisms. 


4. Extension Overview 


This section provides a brief overview of the "tls_cert_with_extern_psk" extension. 


The client includes the "tls_cert_with_extern_psk" extension in the ClientHello message. The 
"tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share", 
"psk_key_exchange_modes", and "pre_shared_key" extensions. The client MAY also find it useful 
to include the "supported_groups" extension. Since the "tls_cert_with_extern_psk" extension is 
intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" 
extension. These extensions are all described in Section 4.2 of [RFC8446], which also requires the 
"pre_shared_key" extension to be the last extension in the ClientHello message. 


Housley Experimental Page 3 


RFC 8773 Certificate with External PSK March 2020 


If the client includes both the "tls_cert_with_extern_psk" extension and the "early_data" 
extension, then the server MUST terminate the connection with an "illegal_parameter" alert. 


If the server is willing to use one of the external PSKs listed in the "pre_shared_key" extension 
and perform certificate-based authentication, then the server includes the 
"tls_cert_with_extern_psk" extension in the ServerHello message. The "tls_cert_with_extern_psk" 
extension MUST be accompanied by the "key_share" and "pre_shared_key" extensions. If none of 
the external PSKs in the list provided by the client is acceptable to the server, then the 
"tls_cert_with_extern_psk" extension is omitted from the ServerHello message. 


When the "tls_cert_with_extern_psk" extension is successfully negotiated, the TLS 1.3 key 
schedule processing includes both the selected external PSK and the (EC)DHE shared secret 
value. (EC)DHE refers to Diffie-Hellman over either finite fields or elliptic curves. As a result, the 
Early Secret, Handshake Secret, and Master Secret values all depend upon the value of the 
selected external PSK. Of course, the Early Secret does not depend upon the (EC)DHE shared 
secret. 


The authentication of the server and optional authentication of the client depend upon the 
ability to generate a signature that can be validated with the public key in their certificates. The 
authentication processing is not changed in any way by the selected external PSK. 


Each external PSK is associated with a single hash algorithm, which is required by Section 4.2.11 
of [RFC8446]. The hash algorithm MUST be set when the PSK is established, with a default of 
SHA-256. 


5. Certificate with External PSK Extension 


This section specifies the "tls_cert_with_extern_psk" extension, which MAY appear in the 
ClientHello message and ServerHello message. It MUST NOT appear in any other messages. The 
"tls_cert_with_extern_psk" extension MUST NOT appear in the ServerHello message unless the 
"tls_cert_with_extern_psk" extension appeared in the preceding ClientHello message. If an 
implementation recognizes the "tls_cert_with_extern_psk" extension and receives it in any other 
message, then the implementation MUST abort the handshake with an "illegal_parameter" alert. 


The general extension mechanisms enable clients and servers to negotiate the use of specific 
extensions. Clients request extended functionality from servers with the extensions field in the 
ClientHello message. If the server responds with a HelloRetryRequest message, then the client 
sends another ClientHello message as described in Section 4.1.2 of [RFC8446], including the same 
"tls_cert_with_extern_psk" extension as the original ClientHello message, or aborts the 
handshake. 


Many server extensions are carried in the EncryptedExtensions message; however, the 
"tls_cert_with_extern_psk" extension is carried in the ServerHello message. Successful 
negotiation of the "tls_cert_with_extern_psk" extension affects the key used for encryption, so it 
cannot be carried in the EncryptedExtensions message. Therefore, the "tls_cert_with_extern_psk" 
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extension is only present in the ServerHello message if the server recognizes the 
"tls_cert_with_extern_psk" extension and the server possesses one of the external PSKs offered by 
the client in the "pre_shared_key" extension in the ClientHello message. 


The Extension structure is defined in [RFC8446]; it is repeated here for convenience. 


struct { 
ExtensionType extension_type; 
opaque extension_data<0..2%16-1>; 
} Extension; 


The "extension_type" identifies the particular extension type, and the "extension_data" contains 
information specific to the particular extension type. 


This document specifies the "tls_cert_with_extern_psk" extension, adding one new type to 
ExtensionType: 


enum { 
tls_cert_with_extern_psk(33), (65535) 
} ExtensionType; 


The "tls_cert_with_extern_psk" extension is relevant when the client and server possess an 
external PSK in common that can be used as an input to the TLS 1.3 key schedule. The 
"tls_cert_with_extern_psk" extension is essentially a flag to use the external PSK in the key 
schedule, and it has the following syntax: 


struct { 
select (Handshake.msg_type) { 
case client_hello: Empty; 
case server_hello: Empty; 


}; 
} CertWithExternPSK; 


5.1. Companion Extensions 


Section 4 lists the extensions that are required to accompany the "tls_cert_with_extern_psk" 
extension. Most of those extensions are not impacted in any way by this specification. However, 
this section discusses the extensions that require additional consideration. 


The "psk_key_exchange_modes" extension is defined in of Section 4.2.9 of [RFC8446]. The 
"psk_key_exchange_modes" extension restricts the use of both the PSKs offered in this 
ClientHello and those that the server might supply via a subsequent NewSessionTicket. As a 
result, when the "psk_key_exchange_modes" extension is included in the ClientHello message, 
clients MUST include psk_dhe_ke mode. In addition, clients MAY also include psk_ke mode to 
support a subsequent NewSessionTicket. When the "psk_key_exchange_modes" extension is 
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included in the ServerHello message, servers MUST select the psk_dhe_ke mode for the initial 
handshake. Servers MUST select a key exchange mode that is listed by the client for subsequent 
handshakes that include the resumption PSK from the initial handshake. 


The "pre_shared_key" extension is defined in Section 4.2.11 of [RFC8446]. The syntax is repeated 
below for convenience. All of the listed PSKs MUST be external PSKs. If a resumption PSK is listed 
along with the "tls_cert_with_extern_psk" extension, the server MUST abort the handshake with 
an "illegal_parameter" alert. 


struct { 
opaque identity<1..2%16-1>; 
uint32 obfuscated_ticket_age; 
} PskIdentity; 


opaque PskBinderEntry<32..255>;3 


struct { 
PskIdentity identities<7..2416-1>; 
PskBinderEntry binders<33..2%16-1>; 
} OfferedPsks; 


struct { 
select (Handshake.msg_type) { 
case client_hello: OfferedPsks; 
case server_hello: uint16 selected_identity; 


; 
} PreSharedKeyExtension; 


"OfferedPsks" contains the list of PSK identities and associated binders for the external PSKs that 
the client is willing to use with the server. 


The identities are a list of external PSK identities that the client is willing to negotiate with the 
server. Each external PSK has an associated identity that is known to the client and the server; 
the associated identities may be known to other parties as well. In addition, the binder validation 
(see below) confirms that the client and server have the same key associated with the identity. 


The "obfuscated_ticket_age" is not used for external PSKs. As stated in Section 4.2.11 of [RFC8446], 
clients SHOULD set this value to 0, and servers MUST ignore the value. 


The binders are a series of HMAC [RFC2104] values, one for each external PSK offered by the 
client, in the same order as the identities list. The HMAC value is computed using the binder_key, 
which is derived from the external PSK, and a partial transcript of the current handshake. 
Generation of the binder_key from the external PSK is described in Section 7.1 of [RFC8446]. The 
partial transcript of the current handshake includes a partial ClientHello up to and including the 
PreSharedKeyExtension.identities field, as described in Section 4.2.11.2 of [RFC8446]. 


The "selected_identity" contains the index of the external PSK identity that the server selected 
from the list offered by the client. As described in Section 4.2.11 of [RFC8446], the server MUST 
validate the binder value that corresponds to the selected external PSK, and if the binder does 
not validate, the server MUST abort the handshake with an "illegal parameter" alert. 
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5.2. Authentication 


When the "tls_cert_with_extern_psk" extension is successfully negotiated, authentication of the 
server depends upon the ability to generate a signature that can be validated with the public key 
in the server's certificate. This is accomplished by the server sending the Certificate and 
CertificateVerify messages, as described in Sections 4.4.2 and 4.4.3 of [RFC8446]. 


TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being 
used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, 
allowing certificate-based authentication for both the client and the server. If certificate-based 
client authentication is desired, this is accomplished by the client sending the Certificate and 
CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 of [RFC8446]. 


5.3. Keying Material 


Section 7.1 of [RFC8446] specifies the TLS 1.3 key schedule. The successful negotiation of the 
"tls_cert_with_extern_psk" extension requires the key schedule processing to include both the 
external PSK and the (EC)DHE shared secret value. 


If the client and the server have different values associated with the selected external PSK 
identifier, then the client and the server will compute different values for every entry in the key 
schedule, which will lead to the client aborting the handshake with a "decrypt_error" alert. 


6. IANA Considerations 


IANA has updated the "TLS ExtensionType Values" registry [IANA] to include 
"tls_cert_with_extern_psk" with a value of 33 and the list of messages "CH, SH" in which the 
"tls_cert_with_extern_psk" extension may appear. 


7. Security Considerations 


The Security Considerations in [RFC8446] remain relevant. 


TLS 1.3 [RFC8446] does not permit the server to send a CertificateRequest message when a PSK is 
being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is offered 
by the client and accepted by the server. However, TLS 1.3 does not permit an external PSK to be 
used in the same fashion as a resumption PSK, and this extension does not alter those 
restrictions. Thus, a certificate MUST NOT be used with a resumption PSK. 


Implementations must protect the external pre-shared key (PSK). Compromise of the external 
PSK will make the encrypted session content vulnerable to the future development of a large- 
scale quantum computer. However, the generation, distribution, and management of the 
external PSKs is out of scope for this specification. 
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Implementers should not transmit the same content on a connection that is protected with an 
external PSK and a connection that is not. Doing so may allow an eavesdropper to correlate the 
connections, making the content vulnerable to the future invention of a large-scale quantum 
computer. 


Implementations must generate external PSKs with a secure key-management technique, such as 
pseudorandom generation of the key or derivation of the key from one or more other secure 
keys. The use of inadequate pseudorandom number generators (PRNGs) to generate external 
PSKs can result in little or no security. An attacker may find it much easier to reproduce the 
PRNG environment that produced the external PSKs and search the resulting small set of 
possibilities, rather than brute-force searching the whole key space. The generation of quality 
random numbers is difficult. [RFC4086] offers important guidance in this area. 


If the external PSK is known to any party other than the client and the server, then the external 
PSK MUST NOT be the sole basis for authentication. The reasoning is explained in Section 4.2 of 
[K2016]. When this extension is used, authentication is based on certificates, not the external 
PSK. 


In this extension, the external PSK preserves confidentiality if the (EC)DH key agreement is ever 
broken by cryptanalysis or the future invention of a large-scale quantum computer. As long as 
the attacker does not know the PSK and the key derivation algorithm remains unbroken, the 
attacker cannot derive the session secrets, even if they are able to compute the (EC)DH shared 
secret. Should the attacker be able compute the (EC)DH shared secret, the forward-secrecy 
advantages traditionally associated with ephemeral (EC)DH keys will no longer be relevant. 
Although the ephemeral private keys used during a given TLS session are destroyed at the end of 
a session, preventing the attacker from later accessing them, these private keys would 
nevertheless be recoverable due to the break in the algorithm. However, a more general notion 
of "secrecy after key material is destroyed" would still be achievable using external PSKs, if they 
are managed in a way that ensures their destruction when they are no longer needed, and with 
the assumption that the algorithms that use the external PSKs remain quantum-safe. 


TLS 1.3 key derivation makes use of the HMAC-based Key Derivation Function (HKDF) algorithm, 
which depends upon the HMAC [RFC2104] construction and a hash function. This extension 
provides the desired protection for the session secrets, as long as HMAC with the selected hash 
function is a pseudorandom function (PRF) [GGM1986]. 


This specification does not require that the external PSK is known only by the client and server. 
The external PSK may be known to a group. Since authentication depends on the public key ina 
certificate, knowledge of the external PSK by other parties does not enable impersonation. Since 
confidentiality depends on the shared secret from (EC)DH, knowledge of the external PSK by 
other parties does not enable eavesdropping. However, group members can record the traffic of 
other members and then decrypt it if they ever gain access to a large-scale quantum computer. 
Also, when many parties know the external PSK, there are many opportunities for theft of the 
external PSK by an attacker. Once an attacker has the external PSK, they can decrypt stored 
traffic if they ever gain access to a large-scale quantum computer, in the same manner as a 
legitimate group member. 
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TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are bound to a specific hash 
function and KDF. By contrast, TLS 1.2 [RFC5246] allows PSKs to be used with any hash function 
and the TLS 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with TLS 1.2 or 
exclusively with TLS 1.3. Given one PSK, one can derive a PSK for exclusive use with TLS 1.2 and 
derive another PSK for exclusive use with TLS 1.3 using the mechanism specified in [IMPORT]. 


TLS 1.3 [RFC8446] has received careful security analysis, and the following informal reasoning 
shows that the addition of this extension does not introduce any security defects. This extension 
requires the use of certificates for authentication, but the processing of certificates is unchanged 
by this extension. This extension places an external PSK in the key schedule as part of the 
computation of the Early Secret. In the initial handshake without this extension, the Early Secret 
is computed as: 


Early Secret = HKDF-Extract(0, 0) 
With this extension, the Early Secret is computed as: 
Early Secret = HKDF-Extract(External PSK, 0) 


Any entropy contributed by the external PSK can only make the Early Secret better; the External 
PSK cannot make it worse. For these two reasons, TLS 1.3 continues to meet its security goals 
when this extension is used. 


8. Privacy Considerations 


Appendix E.6 of [RFC8446] discusses identity-exposure attacks on PSKs. The guidance in this 
section remains relevant. 


This extension makes use of external PSKs to improve resilience against attackers that gain 
access to a large-scale quantum computer in the future. This extension is always accompanied by 
the "pre_shared_key" extension to provide the PSK identities in plaintext in the ClientHello 
message. Passive observation of the these PSK identities will aid an attacker in tracking users of 
this extension. 
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